Method for enabling a trusted dialog for collection of sensitive data

ABSTRACT

The present invention is a method for enabling a trusted dialog for collection of sensitive data, including the steps of: storing a personal security token specified by a user; receiving an input dialog request from an application; determining whether the application is a signed application; and, if a determination is made that the application is a signed application, accessing the personal security token and allowing the input dialog to be displayed with the personal security token and signed application identification. The personal security token may be at least one of an audible recording or a set of vibratory motions.

CROSS REFERENCE TO RELATED DOCUMENTS

The present invention is a continuation-in-part under 35 U.S.C. § 120 ofU.S. application Ser. No. 10/981,253, filed on Nov. 4, 2004 which isherein incorporated by reference in its entirety.

FIELD OF INVENTION

The present invention relates to the field of computing and particularlyto a method and program for enabling a trusted dialog for collection ofsensitive data.

BACKGROUND OF THE INVENTION

Computing devices are being utilized to perform an ever-increasingnumber of tasks, some of which involve a user entering and/or storingprivate or sensitive data, such as when performing online bankingtransactions, making an online purchase or monitoring personal finances.Consequently, protection of such data from exploitation is becoming anincreasingly important issue. On many software platforms, users areallowed to install software. This is problematic in that a user mayunintentionally install a rogue application, which can compromise thesecurity of both the software platform and the user's sensitive data. Tosome extent, such applications can be “sandboxed” to prevent them fromaccessing certain data and resources. However, by their very nature,rogue applications are almost always given access to a display of thecomputing device. This presents the potential problem of a rogueapplication spoofing the appearance of a legitimate or trustedapplication and soliciting sensitive data from a user, such as passwordsor credit card numbers, which can then be exploited.

Currently employed techniques to prevent a rogue application spoofingthe appearance of a legitimate or trusted application are insufficient.One approach has been to use signed applications. However, such approachis limited by the fact that a rogue application may be signed making alone test for signed code invoking dialog insufficient. An additionalapproach has been to use a “trusted” indicator on a display screen toallow a user to obtain dialog origin information. Again, this approachis limited also because a rogue application may spoof the appearance ofthe entire display screen including the “trusted” indicator. A furtherapproach has been to allow a user to enter a key combination to displayoriginator of dialog which is not able to be intercepted. This approachis non-intuitive and not user friendly.

Therefore, it would be advantageous to have a method for enabling atrusted dialog for collection of sensitive data, which allows a user tohave increased confidence that any input data is being collected by anapplication with a legitimate need for such data.

SUMMARY OF THE INVENTION

Accordingly, the present invention is directed to a method for enablinga trusted dialog for collection of sensitive data, which includes thesteps of: storing a personal security token specified by a user;receiving an input dialog request from an application; determiningwhether the application is a signed application; and, if the applicationis a signed application, accessing the personal security token andallowing the input dialog to be displayed with the personal securitytoken and signed application identification.

It is to be understood that both the foregoing general description andthe following detailed description are exemplary and explanatory onlyand are not necessarily restrictive of the invention as claimed. Theaccompanying drawings, which are incorporated in and constitute a partof the specification, illustrate embodiments of the invention andtogether with the general description, serve to explain the principlesof the invention.

BRIEF DESCRIPTION OF THE DRAWINGS

The numerous advantages of the present invention may be betterunderstood by those skilled in the art by reference to the accompanyingfigures in which:

FIG. 1 is a flowchart illustrating a method for enabling a trusteddialog for collection of sensitive data in accordance with an exemplaryembodiment of the present invention;

FIG. 2 is a flowchart illustrating an additional method for enabling atrusted dialog for collection of sensitive data in accordance with anexemplary embodiment of the present invention, in particular, the stepsby which a platform service receives an input dialog request when asigned application places a call to the platform service via a classpath;

FIG. 3 is a flowchart illustrating a further method for enabling atrusted dialog for collection of sensitive data in accordance with anexemplary embodiment of the present invention, wherein the personalsecurity token is at least one of an audible recording or combination ofvibrations; and

FIG. 4 is a flowchart illustrating a method for enabling a trusteddialog for collection of sensitive data in accordance with an exemplaryembodiment of the present invention.

DETAILED DESCRIPTION OF THE INVENTION

Reference will now be made in detail to the presently preferredembodiments of the invention, examples of which are illustrated in theaccompanying drawings.

Referring to FIGS. 1 and 2, a method for enabling a trusted dialog forcollection of sensitive data in accordance with an embodiment of thepresent invention is discussed. The method 100 includes storing apersonal security token specified by a user 102. In a presentembodiment, a user of a computing device, such as a personal computer,personal digital assistant (PDA) and the like, during initialsetup/login, is asked by the software platform of the computing deviceto enter or select a personal security token. For example, the softwareplatform may cause a message or prompt to be generated and displayed ona display screen of the user's computing device asking the user to entera personal security token. The personal security token is selected bythe user, via keyboard or mouse entry, and is stored by a platformservice in a memory of the user's computing device 102. In a furtherembodiment, the personal security token is stored by a platform servicein a memory of a remotely located computing device. In a presentembodiment, the platform service is software implemented within theoperating system of a user's computing device. In a further embodiment,the platform service software may be obtained and implemented within auser's computing device as an add-on feature. In an embodiment, thepersonal security token is an image or a portion thereof. For example,the image may be 32×32 or 16×16 pixels. In a further embodiment, thepersonal security token is a user-entered alpha/numeric characterstring. In additional embodiments, the personal security token may bechanged as desired by the user.

The method 100 further includes receiving an input dialog request froman application 104. An input dialog is a message or prompt which appearson a display screen of a user's computing device and solicits a userresponse. For example, an input dialog may ask a user to input sensitivedata, such as a password or a credit card number to be used by acorresponding application. If the corresponding application is a trustedapplication with a legitimate need for such data, a user can feel securewhen providing information in response to that application's inputdialog. However, in some cases, an input dialog may come from a rogue(i.e.—untrustworthy) application that has been installed, perhapsunintentionally, by the user. Rogue applications may generate an inputdialog that spoofs the appearance of an input dialog from a trustedapplication. Consequently, a user may be deceived into providingsensitive data in response to a rogue application's input dialog, thusallowing for possible exploitation of such data. In a presentembodiment, a platform service, such as a secure dialog service,receives an input dialog request from an application 104 which isattempting to have its input dialog displayed on a display screen of auser's computing device. In a present embodiment, the user's computingdevice contains a Java Virtual Machine (JVM) and the platform servicereceives the input dialog request from an application, which places acall to the platform service via a class path.

FIG. 2 illustrates a method 200 in accordance with the presentembodiment of the invention, in particular, the steps by which aplatform service receives an input dialog request when a signedapplication (i.e.—an application containing a digital signature) placesa call to the platform service via a class path. First, a generic classloader of the JVM receives a request to load application code package202. The generic class loader then verifies that the application codepackage is signed 204. The generic class loader transfers theapplication code package to a signed-class loader 206. The signed-classloader verifies the presence of proper certificate signatures and loadsapplication classes 208. The signed-class loader then calls applicationentry point 210, which causes an execution call stack of the applicationto show the signed-class loader as the root of the call stack. Finally,the platform service receives the application's input dialog request212.

Once an input dialog request from an application has been received 104,the method 100 further includes determining whether the application is asigned application 106. In a present embodiment, the platform service,upon receiving an input dialog request from an application, determinesif the requesting application is a signed application 108. In thepresent embodiment, the platform service determines if the requestingapplication is a signed application by examining the application'sexecution call stack. If the execution call stack shows the signed-classloader as the root of the call stack, the platform service makes thedetermination that the application has been verified as a signedapplication and is thus, legitimate. The platform service operates underthe assumption that a rogue application cannot spoof an execution callstack. If the platform service determines that the requestingapplication is signed 110, the platform service accesses the storedpersonal security token, which the requesting application does not know,and allows the application's input dialog to be displayed on a displayof the user's computing device, the input dialog including the personalsecurity token and the application's certificate information (i.e.,dialog origin information), which identifies the application as a signedapplication 110. A user seeing an input dialog on his or her computingdevice's display which includes the user's personal security token andthe application's certificate information can be confident that thedialog is from the signed application identified in the dialog.Conversely, if the platform service determines that the application isnot signed 112, the input dialog will not be displayed with the personalsecurity token and will not include signed application identification.

Referring to FIGS. 3 and 4, additional methods for enabling a trusteddialog for collection of sensitive data in accordance with embodimentsof the present invention are provided. The method 300 includes storing apersonal security token specified by a user 302 in which the personalsecurity token is at least one of an audible recording or a set ofvibratory motions. For instance, various vibration combinations in acellular phone may be used as the personal security token.

In the present embodiment, a user of a personal computer, PDA, cellularphone and other like computing devices, during initial setup/login, maybe asked by the software platform of the device to enter or select apersonal security token. The platform service may be softwareimplemented within the operating system of a user's computing device.Further, the platform service software may be obtained and implementedwithin a user's computing device as an add-on feature.

In an exemplary embodiment, the software platform may cause a message orprompt to be generated and displayed on a display screen of the user'scomputing device asking the user to enter a personal security token. Insuch embodiment, the personal security token (being either an audiblerecording or set of vibratory motions) is selected by the user, viakeyboard or mouse entry, and is stored by a platform service in a memoryof the user's computing device or by a platform service in a memory of aremotely located computing device. For example, a user may create or usean audible recording as the personal security token by activating aninput key which records the user's voice. The personal security tokenmay then in the future be supplied by the device recognizing the user'svoice, or by supplying the audible recording to the device. It isfurther contemplated that the user may select an audible recordingsupplied by the computing device to be used as their personal securitytoken. In addition, various vibration combinations/patterns eitherprovided by the computing device or programmed into the device by theuser may also be used as the personal security token. It is to beunderstood that the personal security token may be changed as desired bythe user.

In a further embodiment, the method 300 includes receiving an inputdialog request from an application 304. As previously described formethod 100, an input dialog is a message or prompt which appears on adisplay screen of a user's computing device and solicits a userresponse. For example, an input dialog may ask a user to input sensitivedata, such as a password or a credit card number to be used by acorresponding application. If the corresponding application is a trustedapplication with a legitimate need for such data, a user may feel securewhen providing information in response to that application's inputdialog. However, in some cases, an input dialog may come from a rogue(i.e.—untrustworthy) application that has been installed, perhapsunintentionally, by the user. Rogue applications may generate an inputdialog that spoofs the appearance of an input dialog from a trustedapplication. Consequently, a user may be deceived into providingsensitive data in response to a rogue application's input dialog, thusallowing for possible exploitation of such data.

In the present embodiment, a platform service, such as a secure dialogservice, receives an input dialog request from an application 304 whichis attempting to have its input dialog displayed on a display screen ofa user's computing device. A JVM may be disposed within the user'scomputing device and the platform service receives the input dialogrequest from an application, which places a call to the platform servicevia a class path.

Once an input dialog request from an application has been received 304,the method 300 further includes determining whether the application is asigned application 306. In a present embodiment, the platform service,upon receiving an input dialog request from an application, determinesif the requesting application is a signed application. For example, theplatform service may determine if the requesting application is a signedapplication by examining the application's execution call stack. If theexecution call stack shows the signed-class loader as the root of thecall stack, the platform service makes the determination that theapplication has been verified as a signed application and is thus,legitimate. The platform service operates under the assumption that arogue application cannot spoof an execution call stack. If the platformservice determines that the requesting application is signed, theplatform service accesses the stored personal security token and allowsthe application's input dialog to be revealed 308. The input dialog mayinclude the personal security token and the application's certificateinformation (i.e., dialog origin information), which identifies theapplication as a signed application. For example, the applicationcertificate information may be revealed on the user's computing devicewhile simultaneously providing the user's personal security token whichis either the user's audible recording or set of vibratory motions. Insuch example, the user may be confident that the dialog is from thesigned application identified in the dialog. Conversely, if the platformservice determines that the application is not signed, the input dialogwill not be revealed with the personal security token and will notinclude signed application identification.

Referring to FIG. 4, a method 400 for enabling a trusted dialog forcollection of sensitive data in accordance with an exemplary embodimentof the present invention is provided. The method 400 utilizes a personalsecurity token which is either an audible recording or a set ofvibratory motions. The method 400 includes storing a personal securitytoken (e.g., specified by a user) in a platform service 402. Again, thepersonal security token is at least one of an audible recording or a setof vibratory motions. Further, the method 400 entails receiving an inputdialog request by the platform service from an application 404 anddetermining whether the application is a signed application byinspecting the application's execution call stack 406. If theapplication is a signed application, the platform service accesses thepersonal security token 408 thereby allowing the input dialog to berevealed with the personal security token and signed applicationidentification. If a determination is made that the application is not asigned application, the application will not be revealed with thepersonal security token and will not include signed applicationidentification 410.

It is contemplated that the invention may take the form of an entirelyhardware embodiment, an entirely software embodiment or an embodimentcontaining both hardware and software elements. In a preferredembodiment, the invention is implemented in software, which includes butis not limited to firmware, resident software, microcode, and the like.Furthermore, the invention may take the form of a computer programproduct accessible from a computer-usable or computer-readable mediumproviding program code for use by or in connection with a computer orany instruction execution system. For the purposes of this description,a computer-usable or computer readable medium may be any apparatus thatmay contain, store, communicate, propagate, or transport the program foruse by or in connection with the instruction execution system,apparatus, or device.

It is further contemplated that the medium may be an electronic,magnetic, optical, electromagnetic, infrared, or semiconductor system(or apparatus or device) or a propagation medium. Examples of acomputer-readable medium include a semiconductor or solid state memory,magnetic tape, a removable computer diskette, a random access memory(RAM), a read-only memory (ROM), a rigid magnetic disk and an opticaldisk. Current examples of optical disks include compact disk-read onlymemory (CD-ROM), compact disk-read/write (CD-R/W) and DVD.

A data processing system suitable for storing and/or executing programcode will include at least one processor coupled directly or indirectlyto memory elements through a system bus. The memory elements may includelocal memory employed during actual execution of the program code, bulkstorage, and cache memories which provide temporary storage of at leastsome program code in order to reduce the number of times code must beretrieved from bulk storage during execution.

Input/output or I/O devices (including but not limited to keyboards,microphone, speakers, displays, pointing devices, and the like) may becoupled to the system either directly or through intervening I/Ocontrollers.

Network adapters may also be coupled to the system to enable the dataprocessing system to become couple to other data processing systems orstorage devices through intervening private or public networks. Modems,cable modem and Ethernet cards are just a few of the currently availabletypes of network adapters.

It is believed that the method of the present invention and many of itsattendant advantages will be understood by the foregoing description. Itis also believed that it will be apparent that various changes may bemade in the form, construction and arrangement of the steps thereofwithout departing from the scope and spirit of the invention or withoutsacrificing all of its material advantages. The form herein beforedescribed being merely an explanatory embodiment thereof.

1. A method for enabling a trusted dialog for collection of sensitive data, comprising: storing a personal security token specified by a user, the personal security token being at least one of an audio recording or a set of vibratory motions; receiving an input dialog request from an application; determining whether the application is a signed application; and if, a determination is made that the application is a signed application, accessing the personal security token and allowing the input dialog to be revealed with the personal security token and signed application identification.
 2. The method for enabling a trusted dialog as claimed in claim 1, wherein the method is implemented in a mobile device.
 3. The method for enabling a trusted dialog as claimed in claim 2, wherein the mobile device is a cellular telephone.
 4. A method for enabling a trusted dialog as claimed in claim 1, wherein the personal security token may be changed as desired by the user.
 5. A method for enabling a trusted dialog as claimed in claim 1, wherein the personal security token is stored in a platform service.
 6. A method for enabling a trusted dialog as claimed in claim 1, wherein receiving the input dialog request from the application is done by a platform service.
 7. A method for enabling a trusted dialog as claimed in claim 6, wherein upon receiving the input dialog request from the application, the platform service determines whether the application is a signed application by inspecting the application's execution call stack.
 8. A method for enabling a trusted dialog as claimed in claim 7, wherein upon determining that the application is a signed application, the platform service accesses the personal security token and allows the application's input dialog to be revealed with the personal security token and signed application identification.
 9. A method for enabling a trusted dialog as claimed in claim 7, wherein if a determination is made that the application is not a signed application, the application is prevented from being revealed with the personal security token.
 10. A method for enabling a trusted dialog as claimed in claim 1, wherein the application does not know the personal security token.
 11. A computer program product, comprising: a computer useable medium including computer usable program code for creating a method for enabling a trusted dialog for collection of sensitive data, the computer program product including: computer usable program code for storing a personal security token specified by a user, the personal security token being at least one of an audio recording or a set of vibratory motions; computer usable program code for receiving an input dialog request from an application; computer usable program code for determining whether the application is a signed application; and, if, a determination is made that the application is a signed application, computer usable program code for accessing the personal security token and allowing the input dialog to be revealed with the personal security token and signed application identification.
 12. A computer program product as claimed in claim 11, wherein instructions are included within the computer readable medium which cause the program, upon receiving the input dialog request from the application, to determine whether the application is a signed application by inspecting the application's execution call stack.
 13. A computer program product as claimed in claim 11, wherein instructions are included within the computer readable medium which cause the program, upon the program making a determination that the application is not a signed application, to prevent the application from being revealed with the personal security token and signed application identification.
 14. A computer program product as claimed in claim 11, wherein the personal security token may be changed as desired by the user.
 15. A computer program product as claimed in claim 11, wherein the personal security token is stored in a platform service.
 16. A method for enabling a trusted dialog for collection of sensitive data, comprising: storing a personal security token specified by a user on a platform service, the personal security token being at least one of an audible recording or a set of vibratory motions; receiving an input dialog request by the platform service from an application; determining whether the application is a signed application by inspecting the application's execution call stack; and if, the application is a signed application, accessing the personal security token by the platform service and allowing the input dialog to be revealed with the personal security token and signed application identification, or if, the application is not a signed application, prohibiting the application from being revealed with the personal security token.
 17. The method for enabling a trusted dialog as claimed in claim 16, wherein the method is implemented in a mobile device.
 18. The method for enabling a trusted dialog as claimed in claim 17, wherein the mobile device is a cellular telephone.
 19. A method for enabling a trusted dialog as claimed in claim 16, wherein the personal security token may be changed as desired by the user.
 20. A method for enabling a trusted dialog as claimed in claim 16, wherein the application does not know the personal security token. 